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Remarks 

This Amendment is accompanied by a Petition for a 1 month 
extension of time and the fees necessitated thereby. 

For the Specification: 

The paragraph beginning on line 10 of page 10 in the 
specification has been amended to correct a clerical error. In 
particular, an inadvertent zero had been inserted into the second 
number delimiting a range of card numbers, thereby causing this 
second number to have 17 digits rather than the typical 16. This 
amendment deletes the inadvertent zero. In addition, a comma has 
been removed in this paragraph to improve the grammar. 

For the Claims : 

The 16 November 2 005 Office Action examined claims 1, 3-8, 
10, 12-23, and 25-40. Each of these claims (i.e., claims 1, 3-8, 
10, 12-23, and 25-40) was rejected. 

Claims 1, 3, 10, 12, 23, 25, and 37 were rejected under 35 
U.S.C. §112, second paragraph as allegedly providing an 
insufficient antecedent basis. In addition, claims 4 and 26 were 
objected to due to alleged informalities. 

Claims 1, 3, 10, 12, 23, and 25 were rejected under 35 
U.S.C. §102 (e) as allegedly being anticipated by Boesch et al . 
(US 5,870,473, hereinafter "Boesch") . Claims 4-8, 13-16, and 26- 
30 were rejected under 35 U.S.C. §103 (a) as allegedly being 
unpatentable over Boesch in view of Boston (EP 0251619, 
hereinafter "Boston") . Claims 17-22 and 31-37 were rejected 
under 35 U.S.C. §103 (a) as allegedly being unpatentable over 
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Boesch and Boston in view of Levine et al . (WO 95/12169, 
hereinafter "Levine") . 

This Amendment amends claims 1, 3-4, 6-8, 10, 12, 15-16, 23, 
25, 26, 28-32, and 36-37. 

Claims 3, 6-8, 15-16, 28-32, and 36 

Claims 3, 6-8, 15-16, 28-32, and 36 are amended herein to 
improve grammar and not for reasons of patentability. In claim 3 
the article a has been added to improve readability. In claims 
6-8, 15-16, 28-30, and 36, claims have been amended to 
consistently recite the singular, possessive form of "merchant" . 
This is done to improve readability and not to limit the scope of 
any claim to only a single "merchant . In claim 30 the word that 
has been added, and in claims 31-32 the word the has been added, 
also to improve readability in both cases. 

Claim Rejections - 35 U.S.C. §112 

With respect to the 35 U.S.C. §112, second paragraph 
rejection of claims 1, 3, 10, 12, 23, 25, and 37, this Amendment 
amends claims 1, 3, 12, 23, 25, and 37. The Office Action 
objects to the recital of several types of codes in these claims 
and alleges insufficient antecedent basis for the corresponding 
limitation in claims 1, 3, 10, 12, 23, 25 and 37. 

In the amended claims the "issuer code or range of issuer 
codes" has been amended to "issuer identifier code or range of 
issuer, identifier codes" - specifically in claims 1, 10, 23 and 
37. Moreover, the "issuer code" in claims 3, 12, and 25 has also 
been replaced by "identifier code", for consistency. 
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An "identifier code" is defined in the specification as the 
portion of a card number which distinguishes between card 
issuers. The following passage is taken from the paragraph of 
applicant's specification beginning on page 10 line 10: 

Typically, payment card issuers are assigned a range of card numbers 
for issuing cards to customers. For example a small bank may be 
assigned the range (...) , whereas a larger bank may be assigned (...) . 
Accordingly, the identifier code is the portion of a card number 
which distinguishes between issuers . 

An "issuer identifier code" is defined in the description as 
a code contained in the bank reference table ( x BRT" ) , which is 
itself "created from a number of sources, including the card 
scheme administration organizations or from data collected from a 
large number of cardholders" (see the specification at page 10 
lines 22-24) . The following passage is taken from the paragraph 
beginning on page 10 line 16 in the specification. 

The identifier code is compared 51 with entries in a bank 
reference table (an example of which is shown in Figure 6) , which 
contains a list of issuer identifier codes . Each issuer identifier 
code 60(l-n) in the table has an associated entry 61(l-n) 
containing an associated currency, which corresponds to the 
currency of payment cardholders accounts of the issuer. 

Accordingly, the "issuer identifier code" term relates to 
"identifier-like" codes that are listed in the BRT. Note that 
issuer identifier codes may be, but are not required to be, 
precisely equivalent to identifier codes, which distinguish 
between card issuers. One way an issuer identifier code may 
differ from an identifier code is that the precise issuer 
identifier codes listed in the BRT may circumscribe a range of 
identifier codes without specifically listing any single code 
actually used by the banking industry within that range. Another 
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way is that some algorithm may be used to translate from actual 
identifier codes into issuer identifier codes that appear in the 
BRT. In this situation, a similar translation when place when an 
identifier code obtained from a card number is compared with 
entries in the BRT. 

There are several references in the specification pointing 
expressly to the interchangeability of "issuer code" with "identifier 
code". Two examples are found in the paragraphs beginning on page 14, 
line 22 and on page 17, line 24, to wit: 

The terminal software searches through the Bank Reference table 
and checks 210 for an entry corresponding to the issuer code 
obtained from the card number . If an entry is found the currency 
for the transaction is set 215 to that of the payment card. If no 
entry in the Bank Reference table is found the currency is set 220 
to that of the merchant. 

And, 

If the transaction is authorised, the Authorisation host extracts 
the issuer code from the payment card details and checks 42 5 the 
extracted issuer code against entries in the bank reference table. 
(...). 

Thus, the issuer identifier code is different, and clearly 
disclosed as such, from the identifier and issuer codes, but the 
identifier and issuer codes are used interchangeably. For 
consistency, throughout the claims (i.e., in claims 3, 12, and 
25) the phrase "issuer code" has been replaced with "identifier 
code" so that the phrase "issuer code" no longer appears in the 
claims . 

Accordingly, the 35 U.S.C. 112, second paragraph rejection 
of claims 1, 3, 10, 12, 23, 25, and 37 has been overcome. 
Reexamination is respectfully requested. 



Claim Objections 
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The Office Action also objects to the recital of "card 
holder" in claims 4 and 26 for reasons of inconsistency. This 
Amendment amends claims 4 and 2 6 to read "cardholder" in a 
consistent manner, instead of "card holder", to overcome this 
objection. Reconsideration is respectfully requested. 

Claim 1 Rejection - 35 U.S.C. §102 

The Office Action rejects claim 1 under 35 U.S.C. §102 (e) as 
being anticipated by Boesch. Reconsideration is respectfully 
requested. 

Applicant respectfully requests the examiner to note that 
the present application has now been pending for well over 5 
years and that the current Office Action is the third Office 
Action and examination undertaken in this matter. The examiner 
is further, respectfully, requested to note the guidelines under 
which patent examiners are required to operate as set forth in 
MPEP 706, namely that "the examiner should never overlook the 
importance of his or her role in allowing claims which properly 
define the invention," and in MPEP 707.07(g), namely that 
" [p] iecemeal examination should be avoided as much as possible." 

Prior Office Actions had rejected applicant's claims over a 
combination of Boston and/or Levine. But those rejections are 
not continued in the present Office Action. Accordingly, it has 
now been recognized that without more, Boston and Levine fail to 
teach, disclose, or suggest the invention defined by applicant's 
claims. The present Office Action now applies a newly cited 
reference, Boesch, against applicant's claims. But Boesch is 
less relevant than Boston and Levine and, at best, teaches 
precisely the same sort of currency determination that is 
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disclosed by Boston and Levine and over which applicant's claimed 
invention is an improvement. 

The continued and prolonged prosecution of the present 
application poses a hardship on the applicant. The examiner is 
respectfully requested to follow MPEP guidelines to avoid 
piecemeal prosecution and to accept "his or her role in allowing 
claims which properly define the invention." 

Boesch discloses a sophisticated system under which customer 
purchases from merchants may be securely made over the Internet. 
This system will be referred to herein as the CYBERCASH system, 
after the name of the assignee of the Boesch reference. The 
thrust of the disclosure is directed toward providing a practical 
but sufficient level of security. It is not directed toward 
currency determination for a transaction between a merchant and a 
customer . 

Applicant's invention as defined in claim 1 is directed 
toward a method "for determining a preferred currency for 
association with a payment card transaction between a merchant 
and a payment card cardholder." While the Boston and Levine 
re f erences that were relied upon in prior Office Actions but are 
now acknowledged as failing to teach, disclose, or suggest 
applicant's claimed invention, were at least related to such 
payment card transactions, Boesch is not. 

Boesch teaches an electronic transfer system for making 
Internet purchases. In accordance with the Boesch system, in 
order to use the Boesch system a customer 2 03 must first 
"register" (using a registration process 401) with a CYBERCASH 
server 100. Registration essentially means the initiation of a 
"persona," which is essentially a collection of data relating to 
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a specific customer client or merchant client of the CYBERCASH 
system. 

Then, in a later operation, the customer must bind an 
instrument. An instrument is a financial instrument, and may 
include a credit card, debit card, demand deposit account (DDA) , 
or the like. The example given toward the end of the Boesch 
specification relates only to the use of a DDA instrument. But 
this instrument is not used to pay a merchant for goods purchased 
over the Internet because the instrument has no bearing 
whatsoever on a transaction between a customer and merchant. 
Rather, that transaction uses electronic cash. 

After binding the instrument, the customer must then load 
funds from the instrument into electronic cash stored in a cash 
container on the CYBERCASH server. At column 6 line 52, Boesch 
defines electronic cash to be "a representation of funds (real 
cash, credit, etc.) used in the present invention.' 7 This is the 
electronic equivalent of making a cash withdrawal from the 
instrument. But instead of getting physical paper money from a 
teller-assisted bank account withdrawal, ATM debit-card 
withdrawal, credit-card advance, etc., the cash is recorded in 
electronic form in the cash container. 

At this point, a customer is ready to go shopping over the 
Internet. In order to use the electronic cash to make an 
Internet purchase, the customer must now open a session where 
security safeguards, such as the maximum duration of the session 
and maximum amount of electronic cash that will be spent, are 
specified. But in order for the customer to use the CYBERCASH 
system, the customer must limit his or her shopping to merchants 
that are also clients of the CYBERCASH system. In particular, 
such merchants must have already registered with the CYBERCASH 



AMENDMENT in response to 16 Nov. 2005 O.A. 
SERIAL NO. 09/613,679 
Page: 2 0 

system, bound their own instrument, and opened their own sessions 
as well. Boesch indicates that the registration, binding, and 
session-opening processes for a merchant are virtually identical 
to the corresponding operations for a customer, except that the 
merchant need not load electronic cash to a CYBERCASH cash 
account because the merchant is expecting to receive electronic 
cash rather than to spend the electronic cash. 

When, while shopping over the Internet, a customer selects a 
product at a specified price from a CYBERCASH- client merchant, 
the customer then makes an election to pay with electronic cash 

(see column 56, lines 18-35) . This initiates a flurry of 
messages between the merchant and customer and between the 
merchant and the CYBERCASH server. As a result of this flurry of 
messages, the electronic cash is deducted from the customer's 
cash container and added to the merchant's cash container. The 
transaction is then complete when the merchant sends the customer 
the purchased product. At a later time, and independent of the 
transaction between customer and merchant, any unused electronic 
cash remaining in the customer's cash container after the 
preceding and other possible customer transactions (whether with 
the preceding merchant or another merchant) , may be unloaded to 
the customer's bound instrument. Likewise, at a later time, and 
independent of the transaction between customer and merchant, all 
accumulated electronic cash accrued in the merchant's cash 
container from the preceding transaction and other transactions 

(whether with the preceding customer or other customers) may be 
unloaded to the merchant's bound instrument. 

Boesch teaches a system where a customer pays for the 
product with electronic cash, not a payment card. The Boesch 
reference explicitly says this at column 6, line 51 and at column 
56, lines 18-35. Moreover, the merchant never learns of any 
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customer payment card or other mode of payment other than 
electronic cash. And, the merchant never learns anything about 
the customer's bound instruments and/or agreements that are 
entered into between the customer and the CYBERCASH system. 
While the Office Action alleges that Boesch teaches a payment 
card transaction, this allegation is a distortion and 
misrepresentation of that which Boesch actually teaches. Such 
distortion and misrepresentation provide strong evidence of the 
inappropriate use of hindsight in performing a patentability 
analysis, where that which appellant teaches (rather than the 
prior art teaching) is used against the applicant. The examiner 
is respectfully requested to follow an appropriate patentability 
analysis where: 

It is impermissible to use the claimed invention as an instruction 
manual or "template" to piece together the teachings of the prior 
art so that the claimed invention is rendered obvious. This court 
has previously stated that " [o] ne cannot use hindsight 
reconstruction to pick and choose among isolated disclosures in 
the prior art to deprecate the claimed invention". In re Fritch 23 
USPQ 2d 1780, 1784 (Fed. Cir. 1992) . 



Moreover, it is not realistic to pick and choose from any one 
reference only so much of it as will support a given position, to 
the exclusion of other parts necessary to the full appreciation of 
what such reference fairly suggests to one of ordinary skill in 
the art (emphasis supplied) . Ingersoll -Rand Co. v. Brunner & Lay, 
Inc. 1177 USPQ 112, 116 (5 th Cir 1973) . 

and, 

In deciding the question of obviousness under 35 U.S.C. §103, it 
is not proper to pick and choose from any one reference only so 
much as it will support a position, to the exclusion of other 
parts necessary to the full appreciation of what such reference 
fully suggests to one of ordinary skill in the art (emphasis 
supplied) . In re Lunsford 148 USPQ 716, 719-720 (CCPA 1966) . 

Ignoring or excluding that which the Boesch reference explicitly 
teaches and instead making a contradictory bald allegation based 
on the language from applicant's claims is an inappropriate 
patentability analysis. It ignores what Boesch fully and fairly 
teaches to those of skill in the art. 
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Boesch fails to teach the use of a "payment card transaction 
between a merchant and a payment card cardholder," but instead 
teaches of an electronic cash transaction between a merchant and 
a payment card cardholder. Boesch likewise fails to anticipate 
applicant's invention as defined in claim 1. Accordingly, 
applicant's claim 1 is believed to be allowable over the Boesch 
reference . 

But claim 1 recites additional features that the Boesch 
reference fails to teach or suggest. For example, applicant's 
claim 1 recites an element of "determining the operating currency 
for said identifier code by comparing said identifier code with 
entries in a table ..." Claim 1 also recites the step of "setting 
the currency for association with the payment card transaction as 
the determined operating currency for the identifier code." 
Boesch fails to disclose or suggest either of these limitations. 

The Boesch reference, like the Boston and Levine references 
primarily relied upon in prior Office Actions and secondarily 
relied upon in the current Office Action, teaches that a 
customer-merchant transaction may take place in a multiple 
currency environment. But that meager teaching falls far short 
of suggesting that which applicant actually recites in claim 1. 
Claim 1 recites an element that specifies how to set the 
currency. And, claim 1 recites the setting of a currency for 
association with a merchant /payment card cardholder transaction. 

Boesch expressly teaches how a currency is set for the 
CYBERCASH system, and that teaching contradicts the bald 
allegation set forth in the Office Action. The allegation set 
forth in the Office Action cites the passage in Boesch between 
column 12 line 50 through column 13 line 10 and at column 14 
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lines 17-30 as teaching these features. This allegation provides 
further distortion and misrepresentation about what the Boesch 
reference fully and fairly suggests to one of skill in the art, 
and provides further evidence of the impermissible use of 
hindsight in making a patentability analysis. 

First, that cited passage in Boesch fails to teach the "how" 
feature that is recited in claim 1. Instead, that passage 
describes items included in a database without any discussion of 
how those items are determined, and certainly without any 
discussion of applicant's recited technique. 

Second, that passage makes no association whatsoever between 
an operating currency and an identifier code. Rather, it merely 
indicates that a currency may be specified. It would be through 
hindsight gained through an understanding of applicant's 
specification and claims that one could even assume that an 
issuer code would have an association with a specified currency. 

The Office Action also cites column 11 lines 26-65 and Figs. 
4K and 5H as teaching applicants recited element of "obtaining 
the card number of the payment card" from which the identifier 
code is identified. This allegation is yet another source of 
misrepresentation. As discussed above, electronic cash rather 
than payment cards are used for CYBERCASH transactions. Even if 
a payment card is used as a bound instrument in the CYBERCASH 
system as a source of electronic cash that can later be used for 
customer-merchant transactions, the number of such a bound 
instrument is not what is recorded in the cited passage. Rather, 
the passage discusses the optional recording of the number of an 
autoclose instrument. The autoclose instrument is an instrument 
where unused electronic cash may be automatically transferred at 
the close of a session. Autoclosing has nothing to do with a 
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customer-merchant transaction and is entirely between the 
CYBERCASH system and a client, whether that client is a customer 
or merchant. The allegation that this passage somehow teaches 
applicant's claimed step of obtaining a payment card card number 
is a misrepresentation of Boesch because Boesch explicitly states 
that w [i]f the instrument being bound is not the autoclose 
instrument, the instrument number is used to compute field 120H.9 
and the instrument number is not stored in field 12 OH. 4 (at 
column 11, line 41-44) and that w [t]he instrument hash of field 
120H.9 is used to verify the instrument number without requiring 
the instrument number to be stored at server computer 100. This 
reduces the attractiveness of server computer 100 as a target for 
thieves and scoundrels" (at column 12 lines 11-15) . 

Furthermore, the Boesch passages cited in the Office Action 
utterly fail to speak to the issue of setting a currency for 
association with a payment card transaction. Rather, they simply 
indicate that a preferred or native currency has been specified. 
The merchant does the same thing as a customer with respect to 
setting a preferred currency (see column 9, lines 28-38, column 
80 lines 2-6) . Nothing in the cited passages indicates how to 
satisfy the conflict when the two currencies do not match. 

On the other hand, the Boesch reference explicitly teaches 
that currency for a customer-merchant transaction is set because 
the customer and merchant each take overt actions to specify the 
currencies they wish to use. No payment card identifier code- 
based or table-based activities are taught or suggested. Rather, 
a customer specifies a currency during the open session process 
207. Boesch explicitly states as much at column 30 lines 17-21, 
again at column 50 lines 13-15, and yet again at column 80 lines 
10-26. The merchant follows the same process, as indicated in 
Boesch at column 9, lines 28-38, column 80 lines 2-6. 
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Thus, Boesch teaches how the customer's and merchant's 
preferred currencies are determined, and the technique taught by 
Boesch differs from that which applicant claims. And Boesch 
further teaches that an instrument number is not stored unless it 
is an autoclose instrument. For this reason, independently of 
and in addition to the above-discussed reason, Boesch fails to 
anticipate applicant's invention as defined in claim 1. 
Accordingly, applicant's claim 1 is believed to be allowable over 
the Boesch reference. 

Nor is applicant's invention as defined in claim 1 rendered 
obvious by Boesch, or by Boesch in combination with the other 
references, including Boston and/or Levine. Applicant's 
responses to prior Office Actions explained how the Boston and 
Levine references disclosed only the traditional technique of 
conducting a multicurrency customer-merchant transaction using 
the merchant's currency as the transaction currency. Applicant's 
claims are now acknowledged as being allowable over the Boston 
and Levine references because those prior rejections are not 
repeated in the current Office Action. Claim 1 defines a 
different method from the traditional technique where the 
currency may be automatically set to a currency preferred by a 
customer (i.e., a payment card cardholder). The automatic part 
of this method is due to obtaining the card number of the payment 
card, identifying an identifier number from this card number, 
setting an operating currency by comparing the identifier number 
with entries in a table, and then setting the currency as the 
determined operating currency. 

The Boesch reference adds nothing to the teaching of Boston 
or Levine. In fact, Boesch teaches away from applicant's claimed 
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invention by again teaching the same merchant -preferred currency 
technique that is the source of the problem applicant's invention 
is aimed at solving. Although ignored by the Office Action, the 
Boesch reference teaches the use of foreign-exchange rates. For 
example, during "open session" message 2 (OS2) the server sends 
the customer a list of foreign-exchange rates that apply to the 
customer's preferred currency. This is done because it is the 
customer who is expected to convert the amount of electronic cash 
he or she will pay in a CYBERCASH-assisted customer-merchant 
transaction. This feature is discussed in Boesch at column 54 
lines 22-29. Note that this OS2 message is sent to the customer 
prior to the customer being able to contact a merchant to 
purchase a product using CYBERCASH'S electronic cash. 

Later, when a CYBERCASH-assisted customer-merchant 
transaction is executed, a "cash 3" (CA3) message is sent from 
the CYBERCASH server to the merchant that again includes a 
foreign- exchange rate. But this foreign- exchange rate is 
transmitted in a customer opaque section of the message. In 
other words, this information is encrypted so that only the 
customer can decrypt it. When the merchant receives this 
encrypted information, the merchant cannot decrypt it but passes 
it on to the customer in a "cash 4" (CA4) message, where the 
customer can then decrypt it and use it to make the appropriate 
updates to its registers that reflect the electronic cash 
transaction. This flow of foreign-exchange rates is discussed in 
the passage that starts at column 70 line 64 and continues to 
column 71 line 55. 

Accordingly, Boesch teaches a system in which only the 
customer uses foreign- exchange rates. Consequently, only the 
customer, and the server that is mirroring the customer's 
calculations, are expected to engage in foreign- exchange 
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calculations. This is precisely the prior art technique that 
poses the problem that applicant's claimed invention is aimed at 
solving. Namely, that the transaction is conducted in the 
merchant's currency. It is always up to the customer to perform 
needed currency conversions using some foreign-exchange rate so 
that the transaction may be successfully drawn to a close. 

The Boesch reference cannot be used to suggest a solution to 
a problem that it failed to recognize and in fact suffers from. 
Accordingly, the Boesch reference does not suggest applicant's 
claimed solution to this problem where a payment card cardholder 
can set the currency for a transaction, and that currency can be 
automatically set in response to data obtained from the payment 
card. - Applicant's invention as defined in claim 1 is not obvious 
over the Boesch reference. And, since the Boston and Levine 
references suffer from the same problem as the Boesch reference, 
as detailed at length in responses to prior Office Actions, they 
add nothing to the teaching of the Boesch reference, and vice- 
versa. Applicant's invention as defined in claim 1 is not 
obvious over the Boesch reference in combination with the Boston 
and/or Levine references. 

Reconsideration of the rejection of claim 1 is respectfully 
requested . 

§102 and §103 Rejections of Claims 3-8 and 31-32 

Each of claims 3-8 and 31-32 depends, either directly or 
indirectly from claim 1. Accordingly, each of claims 3-8 and 31- 
32 is deemed allowable for at least the same reasons as set forth 
above in connection with claim 1. The teaching of Boston and/or 
Levine does not further the teaching of Boesch with respect to 
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these features, as discussed above and as discussed in responses 
to previous Office Actions. Reconsideration is respectfully 
requested . 

Claim 10 Rejection - 35 U.S.C. §102 

Unlike claim 1, claim 10 is expressed in the terms of a 
system. But in spite of certain differences, claims 1 and 10 
share some similar features, including the features generally 
discussed above in connection with claim 1. Accordingly, claim 
10 is deemed allowable over Boesch and also over Boesch in 
combination with the other prior art of record for substantially 
the same reasons as are set forth above in. connection with claim 
1. Reconsideration is respectfully requested. 

§102 and §103 Rejections of Claims 12-22 and 33-34 

Each of claims 12-22 and 33-34 depends, either directly or 
indirectly from claim 10. And, claim 10 has certain features 
generally in common with claim 1, as discussed above. 
Accordingly, each of claims 12-22 and 33-34 is deemed allowable 
for at least the same reasons as set forth above in connection 
with claims 1 and 10. The teaching of Boston and/or Levine does 
not further the teaching of Boesch with respect to these 
features, as discussed above and as discussed in responses to 
previous Office Actions. Reconsideration is respectfully 
requested. 

Claim 23 Rejection - 35 U.S.C. §102 



Unlike claim 1, claim 23 is expressed in the terms of a 
computer program. But in spite of certain differences, claim 23 
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also shares some similar features with claim 1, including the 
features generally discussed above in connection with claim 1. 
Accordingly, claim 23 is deemed allowable over Boesch and also 
over Boesch in combination with the other prior art of record for 
substantially the same reasons as are set forth above in 
connection with claim 1. Reconsideration is respectfully 
requested. 

§102 and §103 Rejections of Claims 25-30 and 35-36 

Each of claims 25-30 and 35-36 depends, either directly or 
indirectly from claim 23. And, claim 23 has certain features 
generally in common with claim 1, as discussed above. 
Accordingly, each of claims 25-30 and 35-36 is deemed allowable 
for at least the same reasons as set forth above in connection 
with claims 1 and 23. The teaching of Boston and/or Levine does 
not further the teaching of Boesch with respect to these 
features, as discussed above and as discussed in responses to 
previous Office Actions. Reconsideration is respectfully 
requested. 

Claim 37 Rejection - 35 U.S.C. §103 

Like claim 1, claim 37 is expressed in the terms of a 
method. But instead of a "setting ..." step as recited in claim 1, 
claim 37 recites an "indicating ..." step along with subsequent 
"receiving ..." and "completing ..." steps. In spite of these 
differences, claim 37 shares some similar features with claim 1, 
including the features generally discussed above in connection 
with claim 1. For the purposes of assessing patentability, claim 
37 is deemed allowable over Boesch in combination with Boston and 
Levine for the same reasons as are set forth above in connection 
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with claim 1. The teaching of Boston and/or Levine does not 
further the teaching of Boesch with respect to these features, as 
discussed above and in as discussed responses to previous Office 
Actions. Reconsideration is respectfully requested. 



Each of claims 38-40 depends, either directly or indirectly 
from claim 37. And, claim 37 has certain features generally in 
common with claim 1, as discussed above. Accordingly, each of 
claims 38-40 is deemed allowable for at least the same reasons as 
set forth above in connection with claims 1 and 37. 
Reconsideration is respectfully requested. 

Applicant believes that the foregoing amendments and remarks 
are fully responsive to the rejections and/or objections recited 
in the 16 November 2 005 Office Action and that the present 
application is now in a condition for allowance. Accordingly, 
reconsideration of the present application is respectfully 
requested. 
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